-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify message verification inside ft_transfer_call for external receiver_id #326
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add tests to ensure that it is working as intended.
When I added new test, I have got some strange case (it related to
So looks like double-spent. I investigated it. It's from canonical implementation (from NEP-141) |
Well, if there are any double spends, this shouldn't be intentional at all, even if it is from a reference implementation. This warrants more investigation to ensure whats going on here. |
…iver_id (#326) * Changed ft_transfer_call and test_ft_transfer_call_fee_greater_than_amount * Modified: checl current_account_id * Added test_ft_transfer_call_without_message * Fix call to ft_resolve_transfer; extend tests (#330) Co-authored-by: Michael Birch <[email protected]>
* Modify message verification inside ft_transfer_call for external receiver_id (#326) * Fix call to ft_resolve_transfer; extend tests (#330) * Fix(precompile): correct ripemd160 word cost (#329) Co-authored-by: Evgeny Ukhanov <[email protected]> Co-authored-by: Joshua J. Bouw <[email protected]> Co-authored-by: Michael Birch <[email protected]>
Currently, we have
NEP-141
compatibility restriction fornETH
. Theft_transfer_call is
not compatible with all kinds of message data because our implementation expects the following format of the message:<near_account_id>:<32 bytes fee><20 bytes for ETH address receiving the fee>
. Having any other message provided or even an empty one (which is a popular option to use for exchanges) will result in a panic and transaction revert.There's a reason why we were doing that: we are making that verification early in order to prevent future panics in
ft_on_transfer
(where it's hard to recover if there's an error). But as the message itself will be used only inside theft_on_transfer
, meaning that the message is intended to be processed by Aurora.As @sept-en suggested we can do this early verification of the message format and overflow checks only if the
receiver_id == aurora
. Because otherwise, it makes no sense to force all other contracts to have the same message format as we do for Aurora.